CI/CD Basics

Introduction

Continuous integration and continuous delivery reduce manual deployment risk by automating validation, packaging, and release steps. Even small self-hosted projects benefit from predictable pipelines that lint, test, and package changes before they reach live systems.

Purpose

CI/CD pipelines help with:

• Fast feedback on changes
• Repeatable build and test execution
• Safer promotion of artifacts between environments
• Reduced manual drift in deployment procedures

Architecture Overview

A basic pipeline usually includes:

• Trigger: push, pull request, tag, or schedule
• Jobs: isolated units such as lint, test, build, or deploy
• Artifacts: build outputs or packages passed to later stages
• Environments: dev, staging, production, or similar release targets

Typical flow:

Commit -> CI checks -> Build artifact -> Approval or policy gate -> Deploy

Core Concepts

Continuous integration

Every meaningful change should run automated checks quickly and consistently.

Continuous delivery

Artifacts are always kept in a releasable state, even if production deployment requires a manual approval.

Continuous deployment

Every validated change is deployed automatically. This is powerful but requires strong tests, rollback paths, and change confidence.

Configuration Example

GitHub Actions workflow example:

name: ci
 
on:
  pull_request:
  push:
    branches: [main]
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm test

Troubleshooting Tips

Pipeline is slow and developers stop trusting it

• Run fast checks early
• Cache dependencies carefully
• Separate heavyweight integration tests from every small change if needed

Deployments succeed but services still break

• Add health checks and post-deploy validation
• Make environment-specific configuration explicit
• Track which artifact version reached which environment

CI and local results disagree

• Match tool versions between local and CI environments
• Keep pipeline setup code in version control
• Avoid hidden mutable runners when reproducibility matters

Best Practices

• Keep CI feedback fast enough to be used during active development
• Require checks before merging to shared branches
• Build once and promote the same artifact when possible
• Separate validation, packaging, and deployment concerns
• Treat pipeline configuration as production code

References

• GitHub Docs: Understanding GitHub Actions
• GitHub Docs: Workflow syntax for GitHub Actions